home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / STUTTGART / CRYPTO / ARCPGP232 / PGPhints < prev   
PGP Signed Message  |  1993-05-21  |  12KB  |  271 lines
  1. -----BEGIN PGP SIGNED MESSAGE-----
  2.  
  3.                        PGPhints Version 3, 21-May-1993.
  4.                        --------------------------------
  5.  
  6. There is a *lot* of documentation for PGP - here are a few hints and tips to
  7. get you started with Archimedes PGP.
  8.  
  9. Revision History:
  10.  
  11.     Version 1, 04-Apr-1993: Initial release.
  12.     Version 2, 14-May-1993: Added info on key-generation.  Added item on
  13.                the problems of taskwindows.  Added warning about taskwindows
  14.                to info on PGPwimp.  Added info on ReadNews scripts for PGP.
  15.                Expanded info on Reader(S).
  16.     Version 3, 21-May-1993: Moved revision history to beginning of file
  17.                to make it easier to see what's changed from the last version.
  18.                Removed info on key-generation problem in taskwindow - release               1.16 of PGP cures the problem. 
  19.  
  20. 1)  Most people install the PGP executable in their library directory
  21.     ($.library), or somewhere else that they've defined to appear on their
  22.     Run$Path.
  23.  
  24. 2)  The filer *must* have seen the !PGP application before you try and use
  25.     PGP, so that the executable knows where keyrings and other important
  26.     files are kept.
  27.  
  28. 3)  If you have more than one filing system, you will have to take steps
  29.     to ensure PGP continues to work no matter what the current filing system
  30.     is.  The simplest way is to redefine Run$Path from
  31.  
  32.         ,%.
  33.  
  34.     to (say)
  35.  
  36.         ,adfs:%.
  37.  
  38.     or, if you have library directories on each FS (presumably each having
  39.     different contents)
  40.  
  41.         ,adfs:%.,scsi:%.
  42.  
  43.     no doubt some of you will have a Run$Path which is even more complex,
  44.     but the principle is the same.
  45.  
  46.     Note that the `.' at the end of the above examples is a part of the
  47.     syntax, not a full stop.
  48.  
  49. 4)  If you don't want to have to type a fully-specified path to a file, set
  50.     the CSD to point to the directory containing that file and then run PGP.
  51.  
  52. 5)  The most useful command is PGP -h, which outputs the contents of pgp/hlp
  53.     to the screen.
  54.  
  55. 6)  If you run PGP in a task window, then you can turn off PGP's inbuilt
  56.     pager by adding the line
  57.  
  58.         pager = "type"
  59.  
  60.     to your config/txt.
  61.     
  62. 7)  PGP may be interrupted at any stage by pressing <Esc>.
  63.  
  64. 8)  PGP normally uses the !PGP folder for temporary files, but you can
  65.     choose to put them elsewhere (a faster hard disc, a slower hard disc
  66.     with more free space, or a RAM disc).
  67.  
  68.     There are two ways of specifying an alternative placement for temporary
  69.     files.  The first is to add a line like
  70.  
  71.         TMP = "RAM:$"
  72.  
  73.     to your config/txt.
  74.  
  75.     However, this means that you always need the RAM disc present when you
  76.     use PGP.  If want to use RAM disc for temporary files only when you're
  77.     encrypting a very large file, you can achieve this by SETting the OS
  78.     variable TMP to RAM:$, running PGP, then UNSETting TMP.
  79.  
  80.     The OS variable TMP overrides any value specified in config/txt, so
  81.     you *can* have your cake and eat it.
  82.  
  83. 9)  Generate a secret key for yourself with PGP -kg.  Most people go for a
  84.     1024-bit key.  I would not recommend using a 384-bit key.
  85.  
  86.     When PGP asks you to type some random text, I would advise that you
  87.     actually copy-type text from a randomly-selected book rather than
  88.     press keys at random - this should generate a wider spread of key-stroke
  89.     timings.
  90.  
  91.     Note that generating a 1024-bit key takes around 3 minutes on an ARM3.
  92.  
  93. 10) Your public key is likely to get passed around and end up on an
  94.     internet public-key server, so pick user-IDs that unambiguously
  95.     specify your address.  It's no good saying that you're Fred Bloggs on
  96.     Dingbat BBS, make it clear that Dingbat BBS is a fido node and give its
  97.     fido address, e.g.,
  98.  
  99.         Fred Xavier Bloggs (Fred Bloggs on Dingbat BBS.  Fido 6:666/66.6)
  100.  
  101.     Another reason fully specifying your user-ID is that people tend to use
  102.     PGP as an email address book.
  103.  
  104. 11) If you have more than one address at which you're happy to receive
  105.     email, add user-IDs for each one.  For instance, if you have an internet
  106.     address and use a BBS, you might add user-IDs like:
  107.  
  108.         Fred Xavier Bloggs <fred.bloggs@foo.bar.com>
  109.         Fred Bloggs on Dingbat BBS.  Fido 6:666/66.6
  110.  
  111. 12) You can't change the text of user-IDs.  What you must do instead is
  112.     add a new user-ID with PGP -ke, then remove the old one with PGP -kr.
  113.  
  114.     Any signatures against the old ID will be lost when it is removed
  115.     (which is as it should be).
  116.  
  117. 13) PGP currently has no way of revoking old user-IDs - even though you
  118.     remove it from your keyring, it will persist on other people's keyrings
  119.     because when they add the new version of your public key PGP merges any
  120.     new user-IDs with user-IDs already present.
  121.  
  122.     The only solution I can think of is to add a new user-ID of the form:
  123.  
  124.         Fred Bloggs on Dingbat BBS is no longer valid - please remove.
  125.  
  126. 14) Some BBS sysops may not permit you to place encrypted mail or files on
  127.     their boards.  Just because they have PGP in their file area, that
  128.     doesn't necessarily mean they tolerate you uploading encypted mail or
  129.     files - so *do* check first.
  130.  
  131. 15) Fido netmail is even more sensitive.  You should only send encrypted
  132.     netmail after checking that:
  133.  
  134.         a) Your sysop permits it.
  135.         b) Your recipient's sysop permits it.
  136.         c) The netmail is sent direct, or arrangements have been made that
  137.            it will be routed through nodes whose sysops also permit it.
  138.  
  139. 16) The most commonly used commands are:
  140.  
  141.         PGP -kg                       generate a secret key for yourself
  142.         PGP -ka <file>                add public key from file
  143.         PGP -kv <id>                  view public keys matching <id>
  144.         PGP -kxa <id> <file>          extract public key for <id> to <file>
  145.         PGP <file>                    decrypt file and/or check signature
  146.         PGP -sta +clearsig=on <file>  sign cleartext message
  147.         PGP -esa <file> <id>          sign <file> and encrypt it to <id>
  148.  
  149.     You don't have to type in a full user-id - PGP will look for keys which
  150.     contain the text given in <id>.  For -kv and -kxa, PGP will return all
  151.     matching keys.  For -esa, PGP will use the first matching key, so you
  152.     must enter enough text to unambiguously specify the desired recipient.
  153.  
  154.     If someone has two different public keys, you can specify the numeric
  155.     key-ID (or part of it) by prefixing it with `0x'.  E.g., to view key-IDs
  156.     matching 9876 use PGP -kv 0x9876.
  157.  
  158.     If you have RISC OS 3, Peter Gaunt's PGPwimp provides a front end
  159.     which means you don't have to remember all those messy commands and
  160.     can either run pgp in a command window or a taskwindow (see the next
  161.     item for pitfalls in running PGP in a taskwindow).
  162.  
  163. 17) When running PGP in a task window, key-presses sometimes appear to get
  164.     `lost' - this appears to be due to a bug in the C `txt' library routines
  165.     as other programs which use them also have this problem.
  166.  
  167.     The `missing' characters have actually registered, it's just that the
  168.     window hasn't been updated correctly - pressing another key will cause
  169.     both it and the missing character to occur.  Since this sometimes happens
  170.     when there is no more text to input (for instance when you press <Return>
  171.     after entering your pass-phrase), it is useful to know that pressing any
  172.     of the four cursor keys will cause the character to appear without
  173.     entering unwanted text.
  174.  
  175. 18) It's *very* much easier to use PGP when it's integrated with your
  176.     mailer.  If you use ReadNews for usenet news and mail, then you should
  177.     pick up a copy of RNscripts4PGP which add PGP functions to ReadNews.
  178.  
  179.     ReadNews is designed to work with RUCP (an Archimedes version of UUCP),
  180.     so these scripts are currently only of use to users with UUCP
  181.     connections.  Some BASIC programs are currently under development which
  182.     allow ReadNews to interoperate with ka9q for users with TCP/IP SLIP
  183.     connections.
  184.  
  185. 19) BBS users probably use Reader (Archimedes BBS format only) or ReaderS
  186.     (multiple BBS formats - shareware).  Currently there is no way of
  187.     integrating PGP with Reader(S).  Decryption is just a matter of
  188.     extracting the relevant message and running PGP on it.  Encryption is a
  189.     little messier:
  190.  
  191.         a) Use your favourite editor to compose your message.  If you're
  192.            replying to a message, extract it as a file (if it's encrypted
  193.            you'll then have to run PGP), and edit the extracted message to
  194.            add your reply.  Save the edit session as a file.
  195.         b) Encrypt the file.
  196.         c) Tell Reader(S) to reply to the message, then drag your encrypted
  197.            reply into the Reader(s) reply window.
  198.  
  199.     When dragging a signed or encrypted file to Reader(S), be careful that
  200.     it doesn't reformat it!  The best way to make sure that reformatting
  201.     doesn't occur is to be careful not to insert or delete any text in
  202.     the reply window after dragging the file.
  203.  
  204. 20) Be very careful with your secret keyring.  Never be tempted to put a
  205.     copy in somebody else's machine so you can sign their public key - they
  206.     could have modified PGP to copy your secret key and grab your
  207.     passphrase.
  208.  
  209. 21) Be careful with your public key.  Exchange floppies rather than let
  210.     somebody copy it from floppy - that way they can't substitute a bogus
  211.     key on your floppy.  At the very least, such a substition would be
  212.     embarassing.  At worst, if your BBS's sysop is the one who substitutes
  213.     a bogus key, your email would be wide open.
  214.  
  215. 22) Don't sign somebody else's key unless:
  216.  
  217.         a) You're absolutely sure they're who they say they are.
  218.         b) You've exchanged keys face-to-face.
  219.         c) The email address given in the user-ID is valid (which you
  220.            check by signing and encypting email to them using the key they
  221.            gave you face-to-face, and they reply in a similar fashion).
  222.  
  223. 23) Do try and exchange keys face-to-face whenever possible.  Acorn
  224.     exhibitions are a very good way of meeting other Archimedes PGP users
  225.     from far and wide.
  226.  
  227. 24) Don't sign X's key just because Y has also signed it.  Your signature
  228.     is your word that you're certain the key is valid.  If you're casual
  229.     about signing keys, people will not trust your signature.
  230.  
  231. 25) PGP warns against trusting unsigned keys downloaded from BBSs.  To some
  232.     extent this is true as the sysop could substitute a bogus key, intercept
  233.     mail, decrypt with the bogus key and re-encrypt with the correct key.  Of
  234.     course, the sysop would have to arrange things so that whenever someone
  235.     downloaded their own key they got the real one, and signed files/public
  236.     messages would have to exist in two versions, but it's not impossible.
  237.  
  238.     This does not mean that you can't use the key for routine email (where
  239.     you're using encryption as an `envelope' for your email) - it can never
  240.     be less secure than plaintext.  However you should not use it for
  241.     `sensitive' information (but people exchanging `sensitive' information
  242.     would presumably exchange keys face-to-face first).
  243.  
  244.     If you know the person whose key you have downloaded well enough to
  245.     recognise their voice, you can telephone them and ask them to read out
  246.     their key's `fingerprint' (obtained with PGP -kvc <id>).  It is up to
  247.     you if you then choose to sign the key (I would not do so unless it was
  248.     somebody I knew *very* well).
  249.  
  250. 26) Don't sign your sysop's key unless you've exchanged keys face-to-face.
  251.     I know you'd expect that downloading the sysop's key from a BBS ought
  252.     to be safe, but what if your friendly local government security agency
  253.     is filtering your comms through a Cray?  For the same reason (and also
  254.     because some people are careless with their passwords), sysops should
  255.     not sign keys uploaded to their board by the key's owner without further
  256.     verifying them.
  257.  
  258. 27) The more public keys you have in your collection, the greater the
  259.     chance PGP can find a certification chain stretching from you to your
  260.     intended recipient.
  261.  
  262. -----BEGIN PGP SIGNATURE-----
  263. Version: 2.2
  264.  
  265. iQCVAgUBK/0nnWv14aSAK9PNAQFpNgP+MVoCXQRhOKWqBTGnKNWCArAb7Erz7w61
  266. SEF+ebr1QmKyaxGD+hsAjkbW7Mb2rLyPUuQjOdjQiUrf50GaRRO1QfWYmQtD0OSk
  267. e4g1d+30YxdPnfya+ovFetjWyQU6twzSdcxnYNsmuMEveSVCx6i1womeb8hPrmlu
  268. StTzkqBJqws=
  269. =FiN3
  270. -----END PGP SIGNATURE-----
  271.